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Description 

SYSTEM AND METHOD FOR 
MULTI-VENDOR AUTHENTICATION TO 
REMOTELY ACTIVATE A 
SOFTWARE-BASED OPTION 

Background of Invention 

[0001] The present invention relates generally to a system to en- 
able software- based options, and more particularly, to re- 
motely verify the status of a multi-vendor supported re- 
mote device and, if the remote device is approved, coordi- 
nate activation of the desired option though the multiple 
vendors. 

[0002] Medical diagnostic devices and supporting systems, such 
as medical imaging systems, have become increasingly 
complex in recent years. Examples of such systems in- 
clude magnetic resonance imaging (MRI) systems, com- 
puted tomography (CT) systems, ultrasound and x-ray 
systems, and positron emission tomography (PET) sys- 



terns. These systems include many different software- 
based options, some of which are not used depending on 
customer needs and costs. To add to the complexity of 
each particular imaging system, many facilities today in- 
corporate a variety of such devices with components from 
various vendors all of which may not be configured identi- 
cally. In larger facilities, the systems may be networked to 
permit common management and control. Further, such 
systems may be networked with a picture archiving and 
communication system (PACS) for storing digitized image 
data for subsequent retrieval and reconstruction. Addi- 
tionally, teleradiology systems that involve transmitting 
digitized image data to remote locations for review and 
diagnosis by specialized physicians and/or radiologists 
may be used as well. 
[0003] Because these medical diagnostic systems are used by 
different facilities with differing needs, not all of these 
systems operate identically. That is, although identical 
software may be installed at the factory, certain options 
are not desired or licensed by a customer or user and, 
therefore, are not enabled when delivered. Furthermore, 
the in-field devices may include components supported 
by different vendors. 



[0004] improvements in computer networks have greatly facili- 
tated the task of offering assistance to remote facilities 
with medical imaging devices. In particular, rather than 
having to call a service center and speak with a technician 
or engineer, or await the arrival of a field engineer, net- 
work technologies have facilitated proactive techniques 
wherein the service center may contact the medical diag- 
nostic devices directly to check the status of the remote 
devices. 

[0005] while such advancements in the provision of remote ser- 
vices to medical diagnostic devices have greatly enhanced 
the level of service and information exchange, they have 
not been used to remotely verify the status of an in-field 
device, grant access to and permit use of software options 
resident on the in-field device. 

[0006] As such, a customer wishing to activate an option must 

contact the vendor of the in-field device, schedule the ar- 
rival of a field engineer, and then wait for the field engi- 
neer to manually evaluate the in-field device and activate 
the software-based option. That is, if a customer later 
wants to add inactive options to their devices, a license 
must be executed and service personnel with appropriate 
training must physically travel to the location where the 



devices are present to enable the software. This process 
can be particularly lengthy and require that the in-field 
device be removed from service during servicing by the 
field engineer. 

[0007] This problem can be compounded when the device is a 
multi-vendor supported device. That is, due to the com- 
plexity of modern medical diagnostic devices, multiple 
vendors may be required to support a device. For exam- 
ple, it is not uncommon for modern medical diagnostic 
devices to incorporate components developed and/or 
supported by a plurality of vendors. As such, when seek- 
ing support of such a device, it may be necessary to con- 
tact multiple vendors. Therefore, a customer wishing to 
activate an option may be required to contact multiple 
vendors, schedule and coordinate the arrival of a field en- 
gineer from the various vendors, and then wait for the 
field engineer to manually evaluate the in-field device and 
activate the software-based option. 

[0008] Therefore, it would be desirable to allow automatic activa- 
tion of a particular option already resident in memory of a 
device without requiring multiple levels of human interac- 
tion to ensure that enabling the particular option is possi- 
ble and can be implemented without impairing the usabil- 



ity of the device. It would be desirable to have a system to 
automatically verify the current status of a device request- 
ing access to a particular option and coordinate activation 
of the option across the multiple support vendors of the 
device. 

Brief Description of Invention 

[0009] The present invention is directed to a system and method 
to automatically respond to a request for activation of an 
option resident on a remote device. The system and 
method are designed to coordinate the activation across 
multiple support vendors such that the requesting cus- 
tomer is presented with a seamless activation process 
with a single vendor. 

[0010] | n accordance with one aspect of the invention, an auto- 
mated method of remotely activating options resident on 
a multi-vendor supported device is disclosed that includes 
receiving, at a centralized facility, an activation key sent 
from a first location and configured to activate an option 
of an in-field device located in a second location. The 
method includes sending the activation key and a verifica- 
tion script, from the centralized facility, to the in-field de- 
vice at the second location. The method then includes re- 
ceiving, at the centralized facility, a report generated by 



the verification script and, if the report is satisfactory, in- 
stalling the activation key in the in-field device to activate 
the option and, if the report is not satisfactory, aborting 
activation of the option. 

[001 1] | n accordance with one aspect of the invention, a system 
to respond to a request to remotely enable an option resi- 
dent on a multi-vendor supported in-field device is dis- 
closed that includes a centralized facility located remotely 
from an in-field device having an inactive option, and the 
centralized facility having at least one access computer. 
The computer is programmed to request an activation key 
from a remote secondary support provider, select a verifi- 
cation script to check that the in-field device is in condi- 
tion to activate the inactive option, and send the verifica- 
tion script and the activation key from the centralized fa- 
cility to the in-field device. The computer is then pro- 
grammed to permit installation of the activation key in the 
in-field device to activate the inactive option if the verifi- 
cation script indicates that the in-field device is in condi- 
tion to activate the inactive option. 

[0012] | n accordance with one aspect of the invention, a system 
to remotely enable an option resident on an in-field de- 
vice is disclosed that includes an in-field device located 



remotely from a centralized facility and a secondary sup- 
port vendor. The in-field device is programmed to send 
an access request to the centralized facility to request ac- 
tivation of an inactive option of the in-field device, receive 
an activation key from the centralized facility that is 
uniquely configured by the secondary support vendor to 
activate the option of the in-field device, and receive a 
verification script from the centralized facility to authenti- 
cate a current status of the in-field device. Then in-field 
device is also programmed to send a report generated by 
the verification script to the centralized facility indicating 
the current status of the in-field device and install the ac- 
tivation key to activate the option if the centralized facility 
indicates the installation is allowable. 
[0013] Various other features, objects and advantages of the 

present invention will be made apparent from the follow- 
ing detailed description and the drawings. 
Brief Description of Drawings 

[0014] The drawings illustrate a preferred embodiment as 

presently contemplated for carrying out the invention. 
[0015] in the drawings: 

[001 6] Fig. 1 is a block diagram of a system for which the present 



invention is implemented therein. 
[0017] pig. 2 is a flow chart showing a process of the present in- 
vention and implemented in the system of Fig. 1. 
Detailed Description 

[0018] Referring to Fig. 1, an overview block diagram of a medi- 
cal diagnostic and service networked system 10 is shown 
which includes a plurality of remote customer stations, 
such as Customer A in a customer station 12 and Cus- 
tomer B in another customer station 14. It is understood, 
that the number of customer stations can be limitless, but 
two specific embodiments are shown with Customer A and 
Customer B, which will be further explained hereinafter. 
The customer stations 12, 14 are connected to a first ven- 
dor located at a centralized facility 16 through a commu- 
nications link, such as a network of interconnected server 
nodes/Internet 18. Although a single centralized facility 
16 is shown and described, it is understood that the 
present invention contemplates the use of multiple cen- 
tralized facilities, each capable of communication with 
each customer station. Each customer station has opera- 
tional software associated therewith which can be config- 
ured, serviced, maintained, upgraded, monitored, enabled 
or disabled by the centralized facility 16. 



[0019] The centralized facility 16 is connected to a second ven- 
dor located at a remote location 20. Although one re- 
motely located secondary vendor 20 is shown and de- 
scribed, it is understood that the present invention con- 
templates the use of multiple secondary vendors at a plu- 
rality of remote locations, each capable of communication 
with the centralized facility 16. 

[0020] The various systems of the customer stations 12, 14 are 
configured to be selectively linked to the centralized facil- 
ity 16 by, for example, a laptop computer 22 connected to 
an internal network 24 of Customer A. Such selective link- 
ing is desirable to provide upgrades, maintenance, ser- 
vice, and general monitoring of the various systems and 
equipment at a customer site, which includes accessing 
data from the systems and transmitting data to the sys- 
tems, for example. 

[0021] | n general, a customer site may have a number of devices 
such as a variety of medical diagnostic systems of various 
modalities and each device may have a variety of enabled 
and disabled options. As another example, in the present 
embodiment, the devices may include a number of net- 
worked medical image scanners 26 connected to an inter- 
nal network 24 served by a single scanner 28 having a 



workstation configured to also act as a server, or config- 
ured as a stand-alone server without a medical image 
scanner associated therewith. Alternately, a customer sta- 
tion, or customer site 14, can include a number of non- 
networked medical image scanners 30, 32, and 34 each 
having a computer or work station associated therewith 
and having an internal modem 36, 38, and 40 to connect 
the remote customer station to a communications link, 
such as the Internet 18 through links 37, 39, and 41, re- 
spectively, to communicate with the centralized facility 
16. Internet 18 is shown in phantom to indicate that an 
external communications network can include Internet 18, 
together with communication links 29, 37, 39, and 41, or 
alternatively, can include direct dial-up links through 
dedicated lines, an intranet, or public communications 
systems. 

[0022] it j S understood that each of the network scanners 26 has 
its own workstation for individual operation and they are 
linked together by the internal network 24 so that the 
customer can have a centralized management system for 
each of the scanners. Further, such a system is provided 
with communications components allowing it to send and 
receive data over a communications link 29. Similarly, for 



the non-networked medical image scanners at remote 
customer station 14, each of the scanners 30, 32, and 34 
have individual communications links 37, 39, and 41. Al- 
though Fig. 1 shows each of these links connected 
through an open network 18, these links can permit data 
to be transferred to and from the systems over a dedi- 
cated network as well. 
[0023] The embodiment shown in Fig. 1 contemplates a medical 
facility having such systems as magnetic resonance imag- 
ing (MRI) systems, ultrasound systems, x-ray systems, 
computed tomography (CT) systems, as well as positron 
emission tomography (PET) systems, or any other type of 
medical imaging system, however, the present invention is 
not so limited. Such facilities may also provide services to 
centralized medical diagnostic management systems, pic- 
ture archiving and communications systems (PACS), tel- 
eradiology systems, etc. Such systems can be either sta- 
tionary and located in a fixed place and available by a 
known network address, or be mobile having various net- 
work addresses. In the embodiment shown in Fig. 1, each 
customer station 12, 14 can include any combination of 
the aforementioned systems, or a customer station may 
have all of a single type of system. A customer station can 



also include a single medical image scanner. Mobile diag- 
nostic systems can be configured similarly to that of cus- 
tomer station 12 or customer station 14. Such mobile di- 
agnostic systems can include equipment of various 
modalities, such as MRI, CT, ultrasound, or x-ray systems 
and are mobilized in order to service patients at various 
medical facilities. 
[0024] a request for access and enablement of software-based 
options of the present invention can be initiated by au- 
thorized personnel, such as an on-line engineer or tech- 
nician, or customer administrative personnel from, for ex- 
ample, a laptop computer 22 connected to a customer in- 
ternal network 24, or individually connected to each of the 
scanners 30, 32, or 34. It is contemplated that the request 
is an enablement request. That is, a given device is origi- 
nally purchased having a plurality of options and a cus- 
tomer, due to pricing considerations, may purchase the 
device with some of the options initially disabled. There- 
fore, an initial purchase of the hardware of the device in- 
cludes a wide variety of options and the customer may 
choose that specific options be disabled to reduce the 
overall purchase price of the device. Accordingly, after 
purchase, the customer may make an enablement or acti- 



vation request to enable any of the options resident on 
the device at the time of purchase but disabled due to 
pricing choices. It is further contemplated that the activa- 
tion request is to enable options added after the initial 
purchase as part of an update or upgrade but disabled to 
reduce the price of the upgrade or update. 

[0025] jo f u |fi|| a request for enablement, the centralized facility 
16 can communicate with a server 42 of the remotely lo- 
cated secondary vendor 20 via a communications link 44. 
Specifically, upon receiving an enablement request, a 
server 46 of the centralized facility 16 contacts the server 
42 of the remotely located secondary vendor 20 and com- 
municates a request for an activation key necessary to 
service the enablement request. The server 42 of the re- 
motely located secondary vendor 20 accesses a database 
56 to retrieve stored device information necessary to gen- 
erate the requested activation key. Once the activation key 
is generated, the server 42 transfers the key to the cen- 
tralized facility 16. 

[0026] a telephone 48 and telephonic connection 50 are pro- 
vided to facilitate communication between the centralized 
facility 16 and the secondary vendor 20. The telephone 48 
and telephonic connection 50 allows the secondary vendor 



20 to communicate with the centralized facility 16 
through an interactive voice recognition system (IVR) 52 in 
the event that generation of the activation key fails. It is 
understood that the IVR system is not only a voice recog- 
nition system, but can also process interactive keypad en- 
try from a touchtone telephone 48. 
[0027] other processor systems of the centralized facility 16 in- 
clude computers to maintain avoicemail system 58, a 
pager system 60, an email system 62, and a main frame 
64, and more generally, an output report generator and 
notifier. Each is connectable and can transmit data 
through a network, such as an Ethernet 66 with one an- 
other, and/or with at least one database 68. However, it is 
understood that the single representation of a database in 
Fig. 1 is for demonstrative purposes only, and it is as- 
sumed that there is a need for multiple databases in such 
a system. A bank of modems 70 is connected to the Eth- 
ernet 66 to relay data from the centralized facility 16 to 
the remote customer stations 12, 14 through a plurality of 
modem links 72. Hence, a system to allow automatic re- 
mote transfer of data and communications between the 
centralized facility 16 and a customer site 12, 14 is pro- 
vided. 



[0028] As previously discussed, each of the systems and substa- 
tions described herein and referenced in Fig. 1 may be 
linked selectively to the centralized facility 16 via a net- 
work 18. According to the present invention, any accept- 
able network may be employed whether public, open, 
dedicated, private, or so forth. The communications links 
to the network may be of any acceptable type, including 
conventional telephone lines, fiber optics, cable modem 
links, digital subscriber lines, wireless data transfer sys- 
tems, or the like. Each of the systems is provided with 
communications interface hardware and software of gen- 
erally known design, permitting them to establish network 
links and exchange data with the centralized facility 16. 
The systems are provided with interactive software so as 
to configure the systems and exchange data between the 
customer stations and the centralized facility 16. In some 
cases, during periods when no data is exchanged between 
the customer stations and the centralized facility, the net- 
work connection can be terminated. In other cases, the 
network connection is maintained continuously. 

[0029] The present invention includes a technique for reviewing a 
remote device for a current status, and if approved for ac- 
tivation, granting access to and remotely permitting use 



of resident software options in the remote device. As pre- 
viously indicated, the device, including medical imaging 
equipment, includes installed software that controls op- 
tions that can be enabled or disabled automatically. The 
present invention is directed toward a method and system 
to automatically and remotely access an in-field device, 
verify the current status of the in-field device, and coordi- 
nate communications between various support vendors to 
enable options resident on the in-field device. 
[0030] From a centralized facility 16, and after appropriate au- 
thentication of the user and validation of the system iden- 
tification and customer's status, the centralized facility 16 
requests an electronic enabler in the form of an activation 
key from the secondary vendor 20. The secondary vendor 
20 generates the activation key and returns it to the cen- 
tralized facility 16, whereby the centralized facility 16 
electronically transmits the activation key to a device via 
the communication links 29, 37, 39, 41, and/or 72. 
Preferably, the communication is over a private communi- 
cation link, but other public communications systems can 
work equally well, such as direct dial-up internet, or wire- 
less communications. As previously set forth, it is under- 
stood that the external communications links include a 



closed intranet system, an open public communications 
system, or a combination thereof. 

[0031] Referring to Fig. 2, the technique is initiated 100 when a 
system identification including customer identification is 
sent from a remote customer station and received at the 
centralized facility 102. It is contemplated that the system 
identification constitutes the initiation of an enablement 
request. That is, the requesting device may have been 
originally purchased having a plurality of options and, due 
to pricing considerations, the device was purchased with 
some of the options initially disabled. Therefore, the ini- 
tial purchase of the hardware of the device included a 
wide variety of options and the customer may have chosen 
that specific options be disabled to reduce the overall 
purchase price of the device. Accordingly, after purchase, 
the customer may make an enablement or activation re- 
quest to enable any of the options resident on the device 
at the time of purchase but disabled due to pricing 
choices. It is further contemplated that the activation re- 
quest may be to enable options added after the initial 
purchase as part of an update or upgrade but disabled to 
reduce the price of the upgrade or update. 

[0032] After receiving the system identification, the centralized 



facility then validates the system identification at 104. 
Validation is determined according to the customer iden- 
tification and/or a passphrase. The system identification 
constitutes a unique identification that enables the cen- 
tralized facility to readily identify the customer making the 
request and the customer's in-field devices. If the cus- 
tomer identification is not valid 106, a prompt for entry of 
a valid customer identification is requested 108. After the 
system identification is validated 104, 110, a request for a 
particular software option that is desired to be activated is 
sent from the in-field device requesting activation and is 
received at the centralized facility 112. The centralized fa- 
cility then validates the activation request at 114. Specifi- 
cally, the centralized facility makes an initial review of the 
activation request by comparing the system identification 
to the activation request. The centralized facility deter- 
mines whether the system is generally capable of the acti- 
vation requested. For example, the centralized facility de- 
termines whether the requested activation has previously 
been made and fulfilled, and therefore, the option is al- 
ready enabled. 

[0033] if the activation request 112 is determined to be invalid 
116, e.g., does not register the requesting in-field device 



as including or supporting the software- based option re- 
quested or the requested option is already active, a mes- 
sage is returned to the in-field device to prompt manual 
contact with the centralized facility 118 and the activation 
is aborted 120. 

[0034] However, if the activation request is determined to be 
valid 122, the in-field device then sends a unique host 
identifier to the centralized facility 124. The unique host 
identifier indicates, to the centralized facility, the specific 
in-field device where activation is requested. Upon receipt 
of the host ID 124, the centralized facility passes the host 
ID to a remotely located secondary vendor in the form a 
request for an activation key 126. 

[0035] Based on the host ID, the remotely located secondary ven- 
dor generates an activation key configured to activate the 
desired option upon installation in the in-field device. 
Concurrently, the centralized facility selects a verification 
script 128 appropriate to determine a current status of 
the in-field device 126. The centralized facility waits for a 
response from the remotely located secondary vendor 
130. It is contemplated that a response may be a receipt 
of the requested activation key 132 or an error communi- 
cation indicating an activation key cannot be generated 



134. If an error report is communicated, the centralized 
facility reviews the report to determine the error and re- 
turns a prompt for manual contact with the centralized fa- 
cility 118, thereby aborting activation 120. 

[0036] on the other hand, once the activation key has been re- 
ceived 132 and the verification script selected 128, the 
centralized facility sends the key and script to the in-field 
device 136. It is contemplated that script and key may be 
sent to the in-field device in a single transmission or 
through multiple transmissions. Furthermore, if a single 
transmission is made, the key and script may be bundled 
together to create a single package that is sent to the in- 
field device. It is further considered that the single pack- 
age may be compressed and/or encrypted to expedite and 
secure transmission. 

[0037] when the in-field device receives the key and script, the 
device unbundles the package, if necessary, and executes 
the verification script 138. The verification script is con- 
figured to automatically determine a current status of the 
in-field device requesting option activation. Specifically, 
the verification script gathers a plurality of current set- 
tings of the in-field device and generates a report. For ex- 
ample, the verification script may determine which op- 



tions are currently active on the in-field device, which op- 
tions are supported by the in-field device, any dependen- 
cies of options supported by the in-field device, as well as 
other similar settings. The report contains information re- 
garding the enableability of the in-field device with re- 
spect to the requested option. That is, the information in- 
cluded in the report pertains to the current setting of the 
in-field device and whether, under those settings, the in- 
field device is in condition to have the requested option 
enabled, i.e. the enableability of the in-field device. The 
information is then used by the verification script to gen- 
erate a report that is sent by the in-field device and re- 
ceived by the centralized facility 140. The centralized fa- 
cility then evaluates the report 142 to determine the en- 
ableability of the in-field device with respect to the re- 
quested option. 

[0038] if the report indicates the device is enableable, the report 
is approved 144 and the centralized facility permits in- 
stallation of the activation key in the in-field device 146. 
Specifically, the centralized facility sends an approval to 
the in-field device whereby the in-field device installs the 
activation key enabling the option 146 and the activation 
of the option is complete 148. However, the centralized 



facility may monitor the use of the option. As such, the 
activation key may contain a preset expiration time, 
whereby the centralized facility may warn the customer of 
an impending expiration. Should the customer elect to re- 
activate the option, the steps described above are re- 
peated and the option is reactivated. 
[0039] However, if the report indicates that the desired option 
cannot readily be activated, the centralized facility does 
not approve the report 150. Accordingly, a message is re- 
turned to the in-field device to prompt manual contact 
with the centralized facility 118 and the activation is 
aborted 120. 

[0040] Accordingly, the present invention includes a method to 
remotely activate an option resident in the memory of an 
in-field device requiring multiple vendor approval without 
requiring the customer to contact each vendor or compro- 
mising the functionality of the in-field device. 

[0041] The present invention includes a method to remotely acti- 
vate options resident on a multi-vendor supported device. 
The method includes receiving, at a centralized facility, an 
activation key sent from a first location and configured to 
activate an option of an in-field device located in a second 
location and sending the activation key and a verification 



script, from the centralized facility, to the in-field device 
at the second location. The method then includes receiv- 
ing, at the centralized facility, a report generated by the 
verification script and, if the report is satisfactory, in- 
stalling the activation key in the in-field device to activate 
the option and, if the report is not satisfactory, aborting 
activation of the option. 
[0042] The present invention includes a system to respond to a 
request to remotely enable an option resident on a multi- 
vendor supported in-field device. The system includes a 
centralized facility located remotely from an in-field de- 
vice having an inactive option, and the centralized facility 
having at least one access computer. The computer is 
programmed to request an activation key from a remote 
secondary support provider, select a verification script to 
check that the in-field device is in condition to activate 
the inactive option, and send the verification script and 
the activation key from the centralized facility to the in- 
field device. The computer is then programmed to permit 
installation of the activation key in the in-field device to 
activate the inactive option if the verification script indi- 
cates that the in-field device is in condition to activate the 
inactive option. 



[0043] The present invention includes a system to remotely en- 
able an option resident on an in-field device. The system 
includes an in-field device located remotely from a cen- 
tralized facility and a secondary support vendor. The in- 
field device is programmed to send an access request to 
the centralized facility to request activation of an inactive 
option of the in-field device, receive an activation key 
from the centralized facility that is uniquely configured by 
the secondary support vendor to activate the option of the 
in-field device, and receive a verification script from the 
centralized facility to authenticate a current status of the 
in-field device. The in-field device is also programmed to 
send a report generated by the verification script to the 
centralized facility indicating the current status of the in- 
field device and install the activation key to activate the 
option if the centralized facility indicates the installation is 
allowable. 

[0044] The present invention has been described in terms of the 
preferred embodiment, and it is recognized that equiva- 
lents, alternatives, and modifications, aside from those 
expressly stated, are possible and within the scope of the 
appending claims. 



